[Feat] Served Laya as a decision model (--model laya-served) - #35

system1-omni's Laya worker pins laya[serve]==0.3.20. Comparing in-process
Laya with the served one (ThinkFlowLab#20) needs the same library on both sides, so the
in-process extra moves from 0.3.9 to 0.3.20. 0.3.20 autocasts to fp16 on
MPS for requests with five or more questions; CPU runs and smaller requests
are unchanged.

docs/served-laya.md designs the served Laya decision model: requirements,
the target interface, what today's server lacks and where each part gets
built, the client (--model laya-served), error handling and trade-offs.

docs/api/laya-systemone.openapi.yaml is the target interface as OpenAPI
3.1 (RFC 9457 errors with stable codes, request ids, Server-Timing,
/livez and /readyz, 503 with Retry-After, served_by per response); each
item is marked implemented or planned. laya-systemone.current.openapi.yaml
specifies today's server (laya-serve 0.3.20 behind the system1-omni
worker and frontend), checked against traffic from a running worker.

ServedLayaModel asks a Laya served over HTTP (system1-omni's worker, its
omni-jev frontend, or plain laya-serve) through POST /v1/systemone, with
the body the in-process model builds (laya_question). The client holds one
deadline per decision, retries once on a dropped connection, 502 or 504,
and after Retry-After on 503, sends one X-Request-Id per decision, and maps
every other status to MODEL_CALL_FAILED or MODEL_SERVICE_CONFIG_ERROR.

Decision.model is the served checkpoint and revision, read from the
response's served_by when a server sends it, else from /health (refreshed
after 30 s, since the worker reports a CPU fallback there), else from
routing.repo against plain laya-serve. The window check is shared with
LayaModel (check_window).

Tests run over httpx.MockTransport: the shared contract, the error and
retry mapping, identity, and responses recorded from a real worker, the
frontend and laya-serve, which are checked against the as-implemented
OpenAPI spec (jsonschema, pyyaml and referencing join the dev extra).

--model laya-served on every agent, on decide, on the rails and in MCP
decide. A test finds any name list, match or Literal that has laya without
laya-served, so a new front cannot miss it.

…nkFlowLab#20)

A tool-front tick keeps Decision.model as model and, from a served model,
served_by, url, request_id and server_timing (Decision.provenance), so a
run's artifacts show the checkpoint, revision and device of each step.

decision-models.md and configuration.md list laya-served and its
variables; served-laya.md gains a run section (start the worker once, use
it from the CLI and MCP) and matches system1-omni#30 on /health freshness
and GPU-only worker options.

A refused connection after the retry now says the worker listens only once
warm and points to system1-omni's recipe; a first /health read that fails
no longer logs about a previous reading that does not exist. The --model
help of every front names laya-served.

90 decisions per configuration on an M1 Pro: in-process Laya, the
system1-omni worker (compile + fp16) and the same worker behind omni-jev
routed every (seed, ticket) pair the same and scored 63/90 each; p50 101,
77 and 82 ms. compare_served.py builds the table from the job dirs and
keeps every decision in served_laya_records.json.

…kFlowLab#20)

The worker now starts as `python -m frontend.laya_mps --compile --weights
fp16` and its /health reports `compile.enabled` instead of `compile.mode`.
served_by records `compiled` (true/false); both specs, the run section
and the not-up message follow. Worker fixtures were recorded again at
3d6cb57; the other responses came out byte for byte the same.

The ticket-router comparison was rerun at 3d6cb57: 63/90 in every
configuration, all 90 decisions routed the same, p50 88 ms in process and
72 ms served, direct and through omni-jev.

…FlowLab#20)

The registration check read s1a's sources with the platform encoding,
cp1252 on Windows, and reported paths with backslashes there. Every new
text read and write now names utf-8, and paths are reported in POSIX form.

…stopped episodes (ThinkFlowLab#20)

The identity refresh every 30 s ran before the decision's deadline began,
so a stalled /health could stretch one decision to LAYA_SERVED_TIMEOUT_S
plus 2 s. The refresh now shares the decision's deadline and takes at most
half of what is left.

compare_served.py paired the batch's ticket ids with the ticks, so a job
with an episode that stopped early raised in zip(). It now pairs the
processed routes with the ticks and checks that each pair agrees.

…rors (ThinkFlowLab#20)

The not-up error quoted the M1 Pro ready time with --compile and fp16,
which misleads on a CPU worker or another Mac; it now says the worker may
still be starting and points to the recipe. The timeout comment gives its
reason instead of a measured latency range, and the browser comment names
served Laya as the HTTP one. The run section quotes the real message.